       ********    **************************************************
             *    *     *   *                                        *
            *     *      *   *      The independent guide to BITNET  *
           *      *           *                                      *
          *       *        *   *
         *        *  *      *                                        *
        *         *   *      *                   Volume 3, Number 8  *
       ********   *    *      *                                      *
                  **    *      *         *                           *
        ***       * *    *                *              *           *
       * * *      *             *          *              *       *  *
       * * *      *              *    *     *              *       * *
       * * *      *        *      *    *     *              *       **
       * **       **        *      *    *             *      *       *
                  * *        *      *    *             *             *
           *      *  *        *           *       *     *       *    *
           *      *   *        *            *      *     *       *   *
       ******     *    *    *                *      *     *       *  *
           *      *          *         *      *      *             * *
           *      *           *         *      *  *   *             **
                  *            *         *         *                 *
       ********   *    *        *    *    *         *      *         *
             *    *     *             *    *         *      *        *
            *     *      *             *                     *    *  *
           *      *       *             *                     *    * *
            *     *   *    *     *       *        *            *    **
             *    *    *          *                *        *        *
       ********   *     *          *    *           *        *       *
                  *      *          *    *           *        *      *
        ***       *       *    *     *    *           *        *     *
       *   *      *             *          *   *            *   *    *
       *   *      *              *          *   *            *       *
       *   *      *     *         *              *         *  *      *
        ***       *      *         *              *         *  *     *
                  *       *   *            *       *         *  *    *
       ******     *        *   *            *                 *      *
           *      *         *   *       *    *            *    *     *
           *      **     *       *       *    *            *         *
           *      * *     *       *       *    *            *   *    *
       ****       *        *               *                 *   *   *
                  *      *  *       *    *  *       *         *   *  *
           *      *  *    *  *       *    *          *             * *
           *      *   *    *       *  *    *     *    *     *       **
       ******     *    *    *       *  *    *     *    *     *       *
           *      *     *    *       *       *     *    *     *    * *
           *      * *    *         *  *             *          *    **
                  *  *              *          *     *          *    *
       ********   *   *              *          *         *          *
           *      **   *      *       *    *     *         *         *
           *      * *   *      *       *    *     *         *        *
           *      *             *   *        *     *         *       *
       ****        **************************************************

1

       *     *  ****** ******* *     *  *****  *     * ******* *     *
       **    * *          *    **   ** *     * **    *    *    *     *
       * *   * *          *    * * * * *     * * *   *    *    *     *
       *  *  * *****      *    *  *  * *     * *  *  *    *    *******
       *   * * *          *    *     * *     * *   * *    *    *     *
       *    ** *          *    *     * *     * *    **    *    *     *
       *     *  ******    *    *     *  *****  *     *    *    *     *
       *                       *     *                               *
        ***********************       *******************************


       Christopher Condon    Editor                   CONDON @ YALEVM
       Timothy Stephen       Associate Editor        STEPHEN @ RPICICGE
       Craig White           Associate Editor         CWHITE @ UA1VM
       June Genis            Contributing Editor      GA.JRG @ STANFORD
       David Hibler          Contributing Editor    ENGL0333 @ UNLVM
       Henry Mensch          Contributing Editor       HENRY @ MITVMA
       Deba Patnaik          Contributing Editor        DEBA @ UMDC
       Gerry Santoro         Contributing Editor         GMS @ PSUVM
       Marc Shannon          Helpdesk Editor        HELPDESK @ DRYCAS
       Glen Overby           Technical Assistant    NCOVERBY @ NDSUVAX
       Gary Moss             Point of View              MOSS @ YALEVM


       ********************* Contents - Issue 29 *********************

        *********
       *     *** *  EDITORIAL PAGE____________________________________
       *    ***  *
       *  ***    *  Bitnotes ....................................... 1
       ***     ***  Writing LISTSERV ..............................  4
       *    ***  *
       *  ***    *
       * ***     *
        *********

        *********
       * ***     *  FEATURES__________________________________________
       * ***     *
       * ****    *  The BITNET/CSNET Merger Study .................. 6
       * *****   *  An Internet Name Server ....................... 13
       * ******  *
       * *** *** *
       * ***  ****
        *********

        *********
       *         *  DEPARTMENTS_______________________________________
       *     *****
       *    ***  *  Headlines ..................................... 15
       *   ***   *  New Mailing Lists ............................. 16
       *  ***    *  Feedback ...................................... 20
       *****     *  NetMonth Policies ............................. 21
       *         *
        *********

      *********************** Distribution: 3792 *********************
1

                                                                Page 1


        *********
       *     *** *  Bitnotes
       *    ***  *
       *  ***    *  by Christopher Condon
       ***     ***
       *    ***  *  Yale University
       *  ***    *
       * ***     *  CONDON@YALEVM
        *********


             "And so, from much reading and little sleep,
              his brain dried up and he lost his wits."

                                       - Cervates, "Don Quixote"


       "The election  vote for the  BITNET-CSNET merger resulted  in a
       strong mandate to the BITNET Board  of Trustees to proceed with
       the merger.  Of the 417 members of BITNET eligible to vote, 216
       votes were cast in the merger election.   Of those, 195 were in
       favor of the  merger and 21 were opposed.    With this mandate,
       the  BITNET   Board  of  Trustees   and  the  CSNET   and  UCAR
       representatives will proceed aggressively, through a Transition
       Team representing both networks, to formulate Bylaws,  a Policy
       Manual,   a  (long-range)   business   plan  and  (short-range)
       transition plan, and other specific components required for the
       merger to actually take place.  As these detailed proposals are
       developed,  the  memberships of the  two networks will  be kept
       informed  and  their  input  will   be  solicited.    There  is
       considerable optimism  that the cost  of the transition  to the
       merged network can be kept far  lower than the costs envisioned
       in the consultant's report.  The incumbents were all re-elected
       to the BITNET Board of Trustees."

                                        - Jim Conklin
                                          Director, BITNIC

       I  have probably  mentioned  before that  there  is an  ancient
       Chinese curse which says,  "May you live in interesting times."
       As I read through the plans  for the BITNET/CSNET merger,  that
       curse came to mind yet again.

       The thought that "all altruists should  be burned at the stake"
       also came to mind,  but that  isn't the subject of this month's
       editorial.

       Interesting times.  Over the next three years, BITNET and CSNET
       as we  know them will cease  to exist and  become...  something
       else.  I have heard the the name "OneNet" thrown around,  but I
1

                                                                Page 2


       don't believe that is official. My guess is that the CSNET name
       will be no more, and the merged networks will still be known as
       BITNET. Of course, that may also be wishful thinking.

       If  I  understand the  text  of  the  plans correctly  (in  the
       Features section of this issue) most of us will not notice that
       a merger is going on, except for the wonderful things that will
       be happening. For example:

       "Realize  a stronger  voice for  the BITNET/CSNET  membership."
       Rather oddly stated,   but true.   BITNET and  CSNET compete in
       many areas for resources (translation:   money)  as well as for
       membership.  A combined network would fix that situation.

       "Realize optional services."  These will be interesting to see.

       "Realize improved chances  for longer term network  services at
       minimal cost."  Translation:    The bigger the network  and its
       financial base, the more stable it will be.   If there are more
       nodes the costs of maintaining the  network will be spread more
       widely.

       "Realize low-cost  service that  will meet  small institutions'
       needs."  Nothing new.

       "Realize  a  wider  financial  base."   See  "Realize  improved
       chances..."

       "Realize  increased   technology  transfer   potential  between
       universities  and  government/industrial users."   A  vaporlike
       benefit,   at best.    We  realize  this presently  though  our
       connections  to  other  networks.    While  the  potential  for
       technology  transfer  may  increase,    I  find  the  actuality
       unlikely.

       This pessimism of mine aside,  I support the merger (not that I
       have much  choice).   That is  because the  current information
       center contractors  (in the case  of BITNET,  EDUCOM)   will be
       maintained until December 31, 1990.   It is interesting to note
       that the  sole benefit  from the  merger noted  for *1991*  is:
       "Realize improved  services."  I am certainly  not anti-BITNIC,
       but I am interested in  what  kind of organization will replace
       it,   or what  it will  become.    I predict  that EDUCOM  will
       continue to administer the network beyond 1991,  no matter what
       the plans say now, but that is beside the point...

       Little is mentioned about  information center services,  except
       that  they  will either  stay  at  their  current level  or  be
       "improved."  I would like to hear more about this,  because the
       information center is where the potential for improving network
1

                                                                Page 3


       is greatest (and  most noticable).   The shakeup  caused by the
       merger  is the  perfect opportunity  to redefine  the scope  of
       responsibility  and   the  staffing  (size)   of   the  Network
       Information Center.

       Perhaps my brain has dried up,  but  it seems to me that is the
       sort of issue that should be  emphasized as we proceed with the
       merger.    Larger  financial  bases  and  increases  technology
       transfer  are  nice,   but  they won't  mean  much  if  network
       information services aren't  expanded to meet the  needs of the
       nineties.

       *****

       In an effort to expand the  ranks of our already bulging ranks,
       I am looking for people who  are willing and capable of writing
       witty,  interesting,  and informative  monthly editorials about
       life in EARN and NetNorth.   We publish lot about the political
       and technical  battles of BITNET,   but we include  very little
       about our  sister networks.    This situation  is,  of  course,
       entirely unfair and should be recitified  at once.   If you are
       interested or  have some ideas,  send  me a note!    Until next
       month...

                                  Virtually,

                                        Chris Condon@YALEVM
1

                                                                Page 4


        *********
       *     *** *  Writing LISTSERV
       *    ***  *
       *  ***    *  by Eric Thomas
       ***     ***
       *    ***  *  Centre Europeen de la Recherche Nucleaire
       *  ***    *
       * ***     *  ERIC@LEPICS
        *********


       I have been asked to provide  some information about the number
       of lines of code in LISTSERV,  the time it took me to write it,
       etc.  I do not believe in  evaluating the amount of programming
       time required by  a project by dividing the amount  of lines of
       code by  some managerial  constants which  supposedly represent
       the  average efficiency  of a  programmer,  but  I respect  the
       religious beliefs of other people, so here's the info.

       LISTSERV is comprised of 12750 lines of documentation and 35500
       lines of code,  of which 6300  are in assembler (the rest being
       REXX).  The documentation  is quite a bit verbose,   as I enjoy
       writing in English  (I take documentation as  a pseudo-literary
       break  in my  grim  everyday  world of  americanized  technical
       jargon).  However, the code is relatively compact, because I am
       very  lazy,   and  do  not  particularly  enjoy  writing  these
       meaningless sentences  using this  ridiculous vocabulary  of 50
       words or so.  Have  a look at the REXX part  of the survey exec
       for an example;  another example could be the LISTSERV database
       functions,  which  fit in 2400  lines of code  (1100 assembler,
       1300 REXX).  The REXX code contains almost no comment (comments
       are for freaks who can't read  core dumps);  the assembler code
       usually has one comment a line, plus a number of block comments
       (I can't stand waiting for the core dump to get printed).

       The internals of LISTSERV were  rewritten twice since the first
       version,  not  in the  "stop and  start from  scratch" way  but
       through a constant evolutionary process:   whenever I needed to
       change a module to fix a bug,  I would carefully review all the
       routines and usually rewrite them,  the  first time to use more
       powerful and efficient  REXX programming techniques that  I did
       not know when  I wrote the very first version,   and the second
       (and most important)  time to adapt  the code to the unexpected
       growth of  the product and  resulting requirements.   The first
       time  LISTSERV had  something like  1/5th  of the  code it  has
       today,  and everything was rewritten.  The second time,  it had
       about 2/3rd of  today's size,  and maybe 2/3rd of  the code was
       rewritten.  That  is,  the  actual amount  of code  I ended  up
       writing is about 60000 lines.
1

                                                                Page 5


       Most of LISTSERV  was written during the  3 years that I  was a
       student in Metz and Paris.  I used  to escape the grim world of
       Supelec every weekend  and come to work  in Centrale (FRECP11).
       The first  morning was  spent reading  and answering  my weekly
       couple of hundred mail files, the afternoon being spent working
       on the system or on other  smaller programs like CHAT or RELAY.
       Sunday was usually dedicated to LISTSERV,   as I prefer to work
       with large time slices.   That is, most of LISTSERV took around
       150 Sundays to write (14-hours Sundays, but then any managerial
       book or Supelec teacher will tell  you that the amount of lines
       you can write a day does not  depend on the number of hours you
       worked  that day,   nor on  the programming  language you  have
       used).  The rest (mostly the UDD) was done at LEPICS,  where it
       is much more difficult to count the  days since I am not forced
       to be away 5 days a week.

       That type of work  is not something that you can  bend into the
       rules  of  computing  project  management  books.   It  is  not
       something you  can put into an  equation,  as in "150/20  = 7.5
       months" or "60000/150 = 400 lines/day". It is not something you
       can control, plan, schedule, monitor, explain, evaluate, audit,
       etc.  It is something that may happen,  or that may not happen,
       but which will  take place or fail to take  place regardless of
       any of these "environmental parameters"  that can be controlled
       by managers.  It is clearly a  process that cannot be owned and
       cannot be controlled,  and therefore  something that no manager
       or politician wants to have to deal with.
1

                                                                Page 6


        *********
       * ***     *  The BITNET/CSNET Merger Study
       * ***     *
       * ****    *  Prepared by Gillepsie, Folkner and Associates
       * *****   *
       * ******  *  a consulting firm
       * *** *** *
       * ***  ****  Send comments to POLICY-L@BITNIC
        *********


       The following document was prepared  by Gillepsie,  Folkner and
       Associates, the consulting firm retained by the BITNET Board of
       Trustees and  the CSNET  Executive Committee  to assist  in the
       study of the  merger.   Your node representative  reviewed this
       document  (among   others)   when  voting  for   the   upcoming
       BITNET/CSNET merger.   In addition to providing some background
       information on reasons behind the merger, it also provides some
       clues as to the changes we can expect in the near future.

       BITNET Board of Trustees Recommendation:

       After many  months of study  by representatives of  both BITNET
       and CSNET,   the BITNET  Board (hereafter  referred to  as "the
       Board")  has recommended that BITNET proceed with the merger of
       the two  networks and  their organizations,   as has  the CSNET
       Executive Committee.  The Board considered the pros and cons of
       this decision at  length in a several-hour  discussion at their
       October  1988  meeting  after  studying  the  Study  Group  and
       consultant's  reports.   The  Board unanimously  felt that  the
       merger was in the best interests  of higher education and would
       present the opportunity to strengthen the networking support of
       our  community by  managing  the common  destinies  of the  two
       organizations to obtain  the most enduring result.    The CSNET
       Board has also unanimously recommended merger.

       This document  is intended to  briefly present  the information
       for the members to make an informed decision.

       * Why are we being presented with this choice?  Since BITNET is
       a membership  managed organization,  the  Board feels  that the
       final decision on the merger should  be made by the membership.
       The  membership is,   therefore,   being  asked to  accept  the
       unanimous  recommendation of  the  Board and  vote  YES to  the
       merger question on the elections ballot.  A two-thirds majority
       favorable vote  will authorize  the Board  to proceed  with the
       merger as described below and,  if satisfied with the proposals
       of the  Transition Team,  to approve  the bylaws of  the merged
       organization, transfer the BITNET assets into it, and terminate
       the present BITNET Corporation.   (Note  that your vote must be
       received by February 6 in order to be counted.)
1

                                                                Page 7


       * Background: Early in 1988 it became apparent that there might
       be several strong  benefits to the merger of  BITNET and CSNET.
       Issues which motivated the investigation were:

       1. Simplify networking life for the end users;

       2. Stimulate  a  move  towards providing  ready and  convenient
       networking for the entire academic and research communities;

       3. Maintain   low-cost   communication   for   all   types   of
       institutions and research users;

       4. Provide  wider connectivity among all fields of intellectual
       endeavor;

       5. Provide  a strong voice in networking for the current BITNET
       and CSNET community;

       6. Offer better services at the same, or lower, cost.

       In February  1988 BITNET  and CSNET decided  to create  a Study
       Group to review a possible merger.    In June 1988 a consulting
       firm (Gillespie,  Folkner & Associates)   was engaged to assist
       the Study  Group by  developing reports  on the  status of  the
       networks  and a  business plan  for  merger.   The  consultants
       provided  reports  and  briefings  to  the  Study  Group  which
       covered:    pertinent  factual   information   about  the   two
       organizations,  including the financial  and membership status;
       risks and  benefits of merger;   national and  regional network
       information and  analysis;  a  series of  financial models  and
       budget estimates; a possible dues structure;  a short and long-
       term plan;   a detailed business  plan.   The  consultants also
       briefed both Boards on the  reports and participated in lengthy
       discussions.

       * Why merge?   The Board projected  BITNET's future,  and it is
       consistent  with   and  enhanced  by   a  merger   with  CSNET.
       Additionally,   a  merger  of BITNET/CSNET  would  provide  the
       following benefits to the BITNET membership:

       1. There will be reduced competition for one niche.  There is a
       need for a medium function network to complement the government
       sponsored NSFnet, but it only makes sense to have one;

       2. There  will  be  a strengthened  voice for  the BITNET/CSNET
       community  as a  merged network.    This  will be  particularly
       important in dealing with such agencies  as the NSF on planning
       and funding matters;

       3. The combined membership will provide a wider financial base;
1

                                                                Page 8


       4. Technology  transfer  will be encouraged  by a good  flow of
       information between universities and government/industry users,
       and between  the two  communities of  expertise represented  by
       BITNET  and  CSNET.    BITNET  and  CSNET  members  will  begin
       collaborating and interacting;

       5. The  combined  network  with professional  management should
       lead to improved services;

       6. There will be improved chances for longer term survival of a
       network which  strongly serves  small institutions  and remains
       low cost to all institutions.    Small institutions will remain
       as a part of the national network;

       7. There  will  be  wider  connectivity   of  disciplines   and
       significant  new international  connections  available to  both
       networks.

       * As in any merger activity,   there are some risks.   The main
       ones are:

       1. There may be some additional costs for merger;

       2. The service level could be affected;

       3. Institutions  that are members  of both networks may combine
       services and cause a loss of total revenue.

       The Board feels that it has  done detailed planning to minimize
       those risks.

       * What is the concept of the new organization?   The concept of
       the merged organization as developed by the consultants is:

       1. A new corporation will be created;

       2. The  merged network's  Governing Board  will be  membership
       controlled with final election procedures to be put in place by
       the bylaws;

       4. There will be an Executive Director supported by a small
       staff.

       * The goals of the merged organization are:

       1. Provide  a  national  and  international,  low-cost  network
       service  for  academic  instruction   and  research,   and  the
       government and industrial research community;
1

                                                                Page 9


       2. Encourage  and  support  national  and international  common
       academic  and industrial  research  interest  groups,  such  as
       computer   scientists,    automotive   engineers,    university
       administrators and historians;

       3. Encourage and  support higher  education institutions of all
       sizes, including those of smaller size;

       4. Provide a strong voice for the community it serves;

       5. Emphasize  a  mail  system that  is easy  to use,   has high
       reliability,  has  a large number  of nodes,  has  fast message
       service, and maintains low costs;

       6. Be self  supporting, which does not preclude seeking outside
       support to further network development and the communication of
       local, national or international scholars;

       7. Foster  "technology  transfer"   between  higher  education,
       government research labs and industry;

       8. Provide  a  full  range  of  services  consistent  with  the
       scholarly mission of the community which the network serves;

       9. Provide  a  class  of service  based on  access-only (usage-
       insensitive) charges;

       10. Provide  excellent  services (at least at  BITNET and CSNET
       levels);

       11. Provide average dues for BITNET and CSNET members that will
       not exceed their previous dues for the same service level;

       12. Provide modern technology.

       * The membership of the merged organization will be:

       1. Colleges and universities of all sizes;

       2. Not-for-profits and governmental agencies;

       3. For-profits  (They  will  be able  to communicate  with each
       other, as well as others.)

       This concept will  be reviewed and finalized  by the Transition
       Team (described later) and approved by the Board.

       * What  is the  membership and  financial state  of BITNET  and
       CSNET?
1

                                                               Page 10


       1. The current goals of BITNET and CSNET  are similar;

       2. While  the  membership  makeup  of  CSNET  is  predominantly
       through  Computer  Science  Departments (53%)   and  BITNET  is
       predominantly university Computer Centers (67%), both encourage
       all disciplines;

       3. In June 1988 membership was CSNET 189 and BITNET 389;

       4. 111 members belong to both CSNET (60%) and BITNET (29%);

       5. Both networks are financially sound.

       * How will the transition  take place?   When?   The transition
       will:

       1. Maintain  current  services and  levels of service  for both
       BITNET and CSNET;

       2. Maintain  self-supporting  capabilities;  Provide continuing
       network  services to  BITNET  and  CSNET members  with  minimal
       disruption;

       3. Maintain  current  information center contractors  (EDUCOM &
       BBN) until December 31, 1990.

       * If  the membership approves  the merger,  the  following will
       occur:

       1. The UCAR  (CSNET is a  project of the University Corporation
       for  Atmospheric Research)   Board  of  Trustees will  vote  on
       approving  the  merger.     The  next  steps  will   assume  an
       affirmative vote;

       2. A Transition Team  (appointed by the BITNET Board and CSNET)
       will  finalize  the  short-term and  long-term  plans  and  the
       budget;

       3. The  BITNET/CSNET  Boards   approve  the   final  short-term
       plan/long-term plan/transition budget and  will appoint a Long-
       term Committee  to build  a long-range  technical plan  for the
       merged network;

       4. The  Transition  Team will execute the  short-term plan with
       the assistance of a consultant(s)   and will produce the merged
       organization's bylaws and incorporation;

       5. The  BITNET Board and CSNET (UCAR) organization will approve
       the new bylaws and incorporation and transfer the two networks'
       assets and membership to the new organization.
1

                                                               Page 11


       6. The  Transition  Team  will be the  primary agents  for UCAR
       management,  the CSNET Executive Committee and the BITNET Board
       of Trustees  to plan and execute  the transition and  to assure
       balanced representation of the two constituencies.

       7. The transition  is  expected to start in  February 1989 with
       incorporation  of the  new  organization  expected in  November
       1989.

       * How will the transition be  financed?   BITNET and CSNET will
       share transition costs.  The out-of-pocket transition costs are
       expected to be on the order  of $500,000 to cover incorporation
       fees,  legal  fees,  planning meetings and  technical meetings.
       Some of these  costs will be encountered  by technical planning
       in  any case.   Each  organization will  be  able  to fund  the
       transition  without additional  funds  from  the members,   but
       outside grants will be sought to minimize these costs.

       * How will I know what is going on during the transition?   The
       BITNET Board  considers it  imperative that  the membership  be
       aware  of  the  transition  activities  and  will  require  the
       Transition Team to issue regular progress reports as milestones
       are reached.

       * How will the merger affect my dues?  In 1989 there will be no
       changes in membership  dues.   Since maintaining low  cost is a
       high priority of  the merged network,  a structure  of dues and
       fees for 1990  has been adopted for the  merged network.   This
       structure minimizes costs.  Some institutions with overlap will
       be able to pay only one set  of dues,  if they chose to combine
       BITNET and CSNET  connections.   Assuming no elected  change in
       service, BITNET members' (class I-IX) costs will be essentially
       unchanged.

       * How will the merger affect my service and cost?   Short-term?
       Long-term?  In 1989 members will:

       1. Continue  in  their   respective  organization   with  their
       appropriate rules, policies and costs;

       2. Continue with  the same  software,  services and information
       centers;

       3. Become members of the merged organization in the latter part
       of the year with no change in software, services or information
       centers.

       In 1990 members will:

       1. Pay dues and fees according to the merged network schedule;
1

                                                               Page 12


       2. Some  institutions will be able  to combine BITNET and CSNET
       services at a lower cost;

       3. Continue with  the same  software,  services and information
       centers;

       4. Realize a stronger voice for the BITNET/CSNET membership;

       5. Realize optional services;

       6. Realize improved chances for longer term network services at
       minimal cost;

       7. Realize  low-cost service that will meet small institutions'
       needs;

       8. Realize a wider financial base;

       9.  Realize  increased  technology  transfer potential  between
       universities and government/industrial users.

       In 1991 members will:

       1. Realize improved services.

       *  What does  it mean  if the  membership votes  yes?   If  the
       membership approves  the merger,   the transition  process will
       begin as outlined previously.   The  BITNET Board will have two
       final approval  actions to consummate  the merger.    The first
       will be the approval of the final plans and budget.  The second
       will be  the approval  of the bylaws  and incorporation  of the
       merged network.   These  events will be handled  carefully with
       every consideration  for the future  of the  BITNET membership,
       but  will  also be  entered  with  the  intention to  merge  as
       expeditiously as reasonable.

       * What does it mean if the membership votes no?   If the BITNET
       membership votes not to approve  the merger,  the networks will
       continue their  separate existence and  we will have  missed an
       opportunity  to become  a stronger  organization  and reap  the
       potential benefits.   Neither network is in immediate financial
       danger, but the regionals are having some effect, and potential
       new members will continue to wonder which network to join.
1

                                                               Page 13


        *********
       * ***     *  An Internet Name Server
       * ***     *
       * ****    *  by Murph Sewall
       * *****   *
       * ******  *  SEWALL@UNCONNVM
       * *** *** *
       * ***  ****  University of Connecticut
        *********


       * Editor's note:    We thought that you might  be interested in
       what the people of the Internet call a "name server."  It turns
       out that we in BITNET can get some use out of it ourselves...

       Have you  ever tried to reply  to mail you've received  only to
       have the SMTP gateway at CUNYVM,  MITVMA,  or CORNELLC (to name
       the  most frequently  used gates)   return your  mail with  the
       message  that  the host  (which  just  sent  mail to  you)   is
       "unknown?"   The  problem  is that  BITNET's  gateways  to  the
       Internet  find hosts  such  as  'simtel20.arpa' or  'think.com'
       which are  connected directly to  the Internet (that  is,  have
       numeric 'IP'  addresses)  but are  unable to locate  hosts with
       domain style  addresses which have  their mail forwarded  by MX
       (Mail eXchange)   hosts.   In other  words,  the  gateway can't
       "lookup" the MX automatically.

       The  solution is  to address  mail  to domains  served by  Mail
       eXchangers by explictily naming the MX on the "To:" line of the
       address.   The problem  is how to identify the MX  host for the
       domain you wish to reach.

       Now  thanks  to Dan  Long  and  the  computer center  staff  at
       sh.cs.net there is a convenient way  for someone at a BITNET to
       determine MX hosts.    A server has been  created which accepts
       domain host  names as  input and  returns the  applicable "name
       server" records.

       Send mail to:
                          nslookup@sh.cs.net
                          (subject line ignored)

       With a text of:
                          host1.domain
                          host2.domain
                          (etc.)

       For example, not long ago, a reader of the SAS-L list asked how
       to reply  to a message  posted by someone  at 'gtelabs.gte.com'
       In order to find out, the following was mailed:
1

                                                               Page 14


       ---------------------------------------------------------------
       From:     Sewall@UConnVM.BITNET
       To:       nslookup@sh.cs.net

       gtelabs.get.com
       ---------------------------------------------------------------

       Here's the reply:

       ---------------------------------------------------------------
       From:  CSNET Domain Name Server Agent 

       Below are  the Domain Name  Server Resource Records  (RR's)  we
       found for the names you asked about.   The most common types of
       RR's are:

       NS -  name of  the machine  that advertises  the RR's  for this
       domain.

       A  - Internet (IP) address.

       MX - names of mail exchangers  that accept mail for this domain
       and  (in   parentheses)   the   precedence  or   priority  used
       (lower=better)  in choosing mail routes.    If your mail system
       doesn't  automatically send  mail via  this MX  host,  you  can
       usually force this routing using:

                 @mxhost:user@domain  or  user%domain@mxhost

       NAME - the canonical name for this domain.  This is essentially
       a pointer  to the official name  for the requested  name.   All
       other RR's will appear under this official name.

       CPU=...  - gives  information about the host  CPU and Operating
       System.

       gtelabs.gte.com      MX = relay2.cs.net (10), relay.cs.net (20)
       relay2.cs.net        A = 192.31.103.5
       relay.cs.net         A = 192.31.103.4, 128.89.0.93
       ---------------------------------------------------------------

       In this case,   you could send mail  to fred@gtelabs.gte.com by
       writing his address in the format:

                     fred%gtelabs.gte.com@relay2.cs.net
                                   - or -
                      fred%gtelabs.gte.com@relay.cs.net
1

                                                               Page 15


        *********
       *         *  Headlines
       *     *****
       *    ***  *  edited by Christopher Condon
       *   ***   *
       *  ***    *  Yale University
       *****     *
       *         *  Send your Headlines to BITLIB@YALEVM
        *********


       * The  Merger Will  Happen:   The  Merger of  BITNET and  CSNet
       passed overwhelmingly,  by  over 90%.   Out of  216 votes,  195
       voted for  the merger  and 21 voted  against the  merger.    In
       related news,  the  four nominees in the  BITNET Board election
       with the largest number of votes are:

            Butch Kemper (Texas A&M)
            Glen Ricart (Maryland)
            Pat Skarulis (Duke)
            Bill Yundt (Stanford)

       * More NETSERVs:   Thanks to Ed  Zawacki and Melvin Klassen for
       their notes about  the net NETSERV file/user  directory servers
       at UICVM and UALTAVM.   These servers  offer the same files and
       services as the other NETSERVs, but will provide faster service
       if you are in their area.

       * The Relay 556@OREGON1 is gone:   When Dave Boyes left Oregon,
       it was shut down permanently.

       * Correction:  The user directory server IDSERVER@PSUVM accepts
       only messages, not mail as previously reported.

       * More LISTSERVs:    Thanks to Dave Young and  Jim McIntosh for
       their notes about the new LISTSERVs  at TRINITY and AUVM.   The
       one at AUVM accepts the /WHOIS command,   and so acts as a user
       directory server.
1

                                                               Page 16

        *********
       *         *  New Mailing Lists
       *     *****
       *    ***  *  edited by Christopher Condon
       *   ***   *
       *  ***    *  Yale University
       *****     *
       *         *  Send your list descriptions to NEW-LIST@NDSUVM1
        *********


       Each of  the lists described here  is maintained on  a LISTSERV
       machine unless otherwise  noted.  To subscribe to  one of these
       lists  you  would  send  the   following  command  to  the  the
       appropriate server via mail or message.

                      SUBSCRIBE listname Your_full_name

       For example,   if your  name is  Kristen Shaw  and you  want to
       subscribe to  a list  described as  "DIAPERS@YALEVM" you  would
       send the following command to LISTSERV@YALEVM:

                       SUBSCRIBE DAIPERS Kristen Shaw

       To  make contributions  to  the list  you  would  send mail  to
       DIAPERS@YALEVM.   Please note that this is just and example and
       to  my  knowledge there  are  no  mailing lists  about  diapers
       (although you never know).

       *****

       NSP-L@RPICICGE - Noble Savage Philosophers

       The following discussion group description should be considered
       a point of departure.  Every journey  starts with a first step,
       and this is NSP-L's first step.  The format and content of this
       discussion group  is open  to change as  our needs  and desires
       change.

       This initial description is intended to provide a framework for
       development,  feel free to send  your own ideas and suggestions
       aimed towards  improving the  flow of  ideas to  NSP-L@RPICICGE
       (i.e. everyone) or USERE9W9@RPITSMTS (just me).

       Second - As this is an  INTRODUCTION to NSP-L,  I would suggest
       that  individuals  who  subscribe  to  NSP-L  please  introduce
       themselves to the others, such as;

       "Hi,  my  name is  Bob,  I'm  a philosohy  major at  PDQU.  The
       department is primarily ...  while I tend to...  So far my work
       has included....  etc."
1

                                                               Page 17


       You, hopefully, get the idea. Provide any pertinent information
       you feel would help others understand your ideas, such as a few
       comments about your department, your academic background,  your
       social  and/or   political  interests,    your  extra-curicular
       activities, your strengths and weaknesses (e.g. I can't spell),
       your reason for subscribing to NSP-L, what you hope to do here,
       what you  hope to  do when  you grow  up (if  you plan  on ever
       'growing up', i.e. Are you a gradual student?), etc.

       Thus far the discussion group has taken the following form:

       Individuals submit  what they  feel is  appropriate and  others
       branch off  from there.   Discussions and  submissions to  NSP-
       L@RPICICGE   will  be   redistributed   automatically  to   all
       subscribers.  Periodically  an editted journal of  articles and
       discourses culled from the ongoing discussion will be developed
       and distributed.  In developing the  journal,  person to person
       correspondence may parallel group discussion in order to lessen
       traffic over BITNET and NSP-L.

       The group discussion will be an 'open forum' exchange of ideas,
       unmoderated by  the list's  owners.  The  on-line journal  will
       originally  be modeled  after NetMonth,   The BITNET  resources
       journal.  NetMonth  creatively utilizes  fixed pitch  character
       only text  formatting techniques,  producing an  attractive and
       very 'readable'  on-line journal suitable  for printing  on any
       printer. (This has been an unpaid advertisement for NetMonth)

       In  practice,  a  topic  is  raised for  discussion.   Everyone
       contributes thoughts,  articles,  references,   etc.  until the
       topic is exhausted or another topic is raised. Sometimes two to
       three topics are on going simultaneously.

       Several individuals have stated that their particular interests
       are not well  supported within their department,   or that they
       have no  consistent and/or  sympathetic forum  for critique  of
       their work.  We felt that NSP-L might be able to provide such a
       forum and may allow otherwise restricted individuals to develop
       their ideas in a less restricted atmosphere.

       During various  periods in a semester  many of us  are probably
       working on papers.   Please consider submitting one  or more of
       these papers to NSP-L@RPICICGE for discussion. This is a rather
       painless way of jumping in feet first.

       Along with any submissions or  instead of an initial submission
       each of us  should take the time to  introduce ourselves.  Make
       your intro as long or short as you see fit, as discussions grow
       we will get to understand each other better and more fully.

       Coordinator: Barry B. Floyd 
1

                                                               Page 18


       PSI@HAMPVMS - Psi Discussion Forum

       PSI is a forum for discussing experiences, questions, ideas, or
       research  having  to  do  with  psi  (e.g.   ESP,   out-of-body
       experiences,   dream   experiments,   and  altered   states  of
       consciousness).  We are especially  interested in hearing about
       personal  experiences,   and  considering  why  and  how  these
       different phenomena happen,  the connections between them,  how
       to bring them  about,  and what psychological  or philosophical
       implications they have.  Send subscription requests to the list
       owner.

       Owner: Ben Geer 


       SPRINT-L@NDSUVM1 - Borland Sprint users

       Undigested discussion of problems, solutions, macros,  formats,
       and so forth, for Borland's Sprint word processor.

       Moderator: WOLFP@GRIN1


       BILLING@HDETUD1 - Billing and changeback of computer resources

       This list is not dedicated to any one product or supplier,  but
       discusses general  issues as well  as detail pertaining  to MVS
       and VM systems only.   A monthly  notebook will be provided for
       logging the discussion,  this notebook  can be obtained without
       being  subscribed to  the  list.   BILLING LOG8901  contains  a
       summary of net mail during the last year on this subject.

       Owner: Rob van Hoboken 


       MICS-L@HDETUD1 - MVS Information Control System

       This  list  is dedicated  to  the  discussion of  Morino's  MVS
       Information Control System. This will be a technically oriented
       list dealing with this product only.

       Owner: Rob van Hoboken 


       MEXICO-L@TECMTYVM - Knowing Mexico

       This list will talk about all the  places and things you can do
       when you visit Mexico. In addition, you will be able to talk to
       people from  some of those places  and discuss with  them about
       cities and spots you would want to visit.  On some occasions we
1

                                                               Page 19


       will  be  able   to  assist  you  with   your  inquiries  about
       restaurants, hotels,  clubs and sightseeing attractions you may
       like to go in your trip.

       In  addition to  all  this information,   every  month we  will
       publish a supplement  with the most complete  information about
       one city  or place of tourist  interest.  The catalog  of these
       supplements  will be  available,  by  request,   from the  list
       owners.

       Owners: Faustino Cantu 
               Antero Cepeda 
               Alfredo Abbud 


       CLASS-L@SBCCVM - Classification

       We are  pleased to  announce the  availability of  a new  list,
       called CLASS-L, which will serve researchers in classification,
       clustering, phylogenetic estimation,  and related areas of data
       analysis.   CLASS-L  provides researchers  with  announcements,
       newsletters,    and   information  about   classification   and
       clustering.

       Owners: Bill Day <WHDAY@MUN)
               Jim Rohlf >


       PHILOSOP@YORKVM1 - Philosophy

       PHILOSOP covers  the arena  of academic  philosophy.   Messages
       posted by subscribers  can be of all sorts:   work in progress,
       comments thereon, advertisements for conferences,  newsletters,
       journals,   or  associations...    job  postings,   conditional
       agreements on social action....  The items  on the list have to
       have some connection with academic  Philosophy;  but that's not
       interpreted narrowly.

       Coordinators: P. A. Danielson 
                     Nollaig MacKenzie 
1

                                                               Page 20


        *********
       *         *  Feedback
       *     *****
       *    ***  *  a Letters Column
       *   ***   *
       *  ***    *  "Letters!  Where are the letters?"
       *****     *
       *         *  Send your letters to BITLIB@YALEVM
        *********


       From:     Hank Nussbacher 
       Subject:  Feedback

       In the January Feedback, Leonard D. Woren wrote:  "I would like
       to point out another trend in libraries:  computerization.   At
       some leading universities (USC is  one;  UCLA is another),  the
       library is investing heavily in computer technology. This takes
       two forms that I'm aware of:  (1) online card catalogs, and (2)
       online databases. I believe that within a few years, people who
       are put off by  computers will be at a big  disadvantage at the
       research libraries."

       I  would  like  to  reinforce   Leonard's  comments  with  some
       developments occuring in Israel. All university library catalog
       systems have  been undergoing computerization  over the  past 2
       years.   These online  card catalogs  are today  interconnected
       among the 7 universities so that a researcher in one university
       can  determine  if  a  book  that  is  unavailable  at  his/her
       university library  is possibly  available at  another library.
       He can then order the book remotely,   and a mobile van makes a
       daily round  of all the  university libraries,  picking  up and
       dropping off books.

       This system works for both English books and Hebrew books (left
       to right  and right to  left).  In  the near future,   with the
       completion of  our Tcp/Ip infrastructure,   all users,   at all
       terminals  in the  network,   will have  access  to the  online
       library catalogs, allowing scientists, researchers and students
       to check for books,  and order them without having to leave the
       terminal they are running their SAS simulation.
1

                                                               Page 21


        *********
       *         *  NetMonth Policies
       *     *****
       *    ***  *  Everything you ever wanted to know...
       *   ***   *
       *  ***    *  ...but were afraid to ask.
       *****     *
       *         *  BITLIB@YALEVM
        *********


       NetMonth is a  network service publication distributed free  of
       charge to  students  and  professionals  in  BITNET  and  other
       networks. This magazine and its companion file, BITNET SERVERS,
       are the  work  of the  BITNET Services Library (BSL) staff  and
       contributors from around the network.

       BITNET SERVERS is BITNETs list of servers and services.  If you
       know of servers not listed in BITNET SERVERS, or if some listed
       are no longer available, please contact the NetMonth Editor.

       * Subscribing to NetMonth and BITNET SERVERS:

       Send  the  following  command  to  LISTSERV@MARIST  by  mail or
       messgage:

            SUBSCRIBE NETMONTH Your_full_name

       A subscriber  can delete  him/herself from  the mailing list by
       sending LISTSERV@MARIST the command:

            UNSUB NETMONTH

       Internet users may use these methods, but must address the mail
       to LISTSERV@MARIST.BITNET

       * Back issues:

       BITNET users  may get NetMonth back issues from the file server
       LISTSERV@CMUCCVMA.  For a list of  files,  send the  server the
       the command:

            INDEX NETMONTH

       * Letters to the Editor:  If  you  have  questions  or comments
       about BITNET or  NetMonth that you would like  to  see  printed
       here, mail  your letter  to BITLIB@YALEVM.  Make  sure that you
       specify in the "Subject:"  header or  somewhere  in  the letter
       that it is for the NetMonth letters column.
1

                                                               Page 22


       * Article Submissions:  The  only  requirements  for   NetMonth
       articles and columns are that they be informative, interesting,
       and concern some BITNET-related topic.  Send your articles  and
       to BITLIB@YALEVM.

       * Printing this file:  VM  users can print  this file  by using
       the "( CC" option of  the PRINT command.   VAX/VMS users should
       RECEIVE NetMonth  with a  format of  FORTRAN.  This  will allow
       page-breaks to be accepted by your printer.


            _
           __-
          __---    The
         __-----   BITNET
        __-------  Services
       ___________ Library                       "Because We're Here."

       ***************************************************************